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REMARKS 

Claims 1,4-8, 11-15, and 18-21 stand rejected for obviousness under 35 U.S.C § 103(a) 
as being unpatentable over Shaffer (U.S. Patent 6,092,114). Claims 2, 3, 9, 10, 16, and 
17 stand rejected for obviousness under 35 U.S.C § 1 03(a) as being unpatentable over 
Shaffer (U.S. Patent 6,092,114) in view of Schwalm, et al, (U.S. Patent No. 5,339,361), 
As will be shown below, neither Shaffer nor Schwalm, either alone or in combination, 
teaches or suggests a method, system, or computer program product for email 
administration as claimed in the present application. Claims 1-21 are therefore patentable 
and should be allowed. Applicants respectfully traverse each rejection individually and 
request reconsideration of claims 1-21. 

Claim Rejections - 35 U.S.C. § 103 

Claims 1, 4-8, 11-15, and 18-21 stand rejected for obviousness under 35 U.S.C § 103(a) 
as being unpatentable over Shaffer (U.S. Patent 6,092,114). Claims 2, 3, 9, 10, 16, and 
17 stand rejected for obviousness under 35 U.S.C § 103(a) as being unpatentable over 
Shaffer (U.S. Patent 6,092,1 14) in view of Schwalm, et al f (U.S. Patent No. 5,339,361). 
Applicants respectfully traverse each rejection. To establish a prima facie case of 
obviousness, three basic criteria must be met. Manual of Patent Examining Procedure 
§2142. The first element of a prima facie case of obviousness under 35 U.S.C. § 103 is 
that there must be a suggestion or motivation to combine the references. In re Vaeck, 947 
R2d 488,493,20USPQ2dl438, 1442 (Fed. Cir. 1991). The second element of a prima 
facie case of obviousness under 35 U.S.C § 103 is that there must be a reasonable 
expectation of success in the proposed combination of the references. In re Merck & Co., 
Inc., 800 F.2d 1091, 1097, 231 USPQ 375, 379 (Fed. Cir. 1986). The third element of a 
prima facie case of obviousness under 35 U.S.C. § 103 is that the proposed combination 
of the references must teach or suggest all of Appli cants' claim limitations. In re Royka, 
490 F.2d 981 s 985, 180 USPQ 580, 583 (CCPA 1974). 
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The References Do Not Teach Or Suggest 
All Of Applicants' Claim Limitations 

In order to establish a prima facie case of obviousness under 35 U.S.C. § 103, Schaffer 
must teach or suggest all of Applicants 1 claim limitations. As discussed below, Schaffer 
does not teach or suggest all of Applicants' claim limitations* Independent claim 1 
claims: 

1 . A method of email administration comprising the steps of: 

receiving in a transcoding gateway from a client device one or more 
email display status attributes describing one or more email display 
capability statuses for a domain; 

recei ving in the transcoding gateway from a sender an email display 
capability status request for the domain, wherein the capability status 
request comprises a domain identification; 

finding, in dependence upon the domain identification, at least one 
email display capability status record for the domain, wherein the 
email display capability status record for the domain comprises at least 
one of the email display capability status attributes; and 

sending at least one of the email display capability status attributes to 
the sender, 

Shaffer Neither Discloses Nor Suggests The 
First Element Of The Independent Claims 

Regarding the first element of claims 1, 8 and 15, the Office Action states that Shaffer 
discloses at column 2, lines 30-65, and at column 6, lines 31-53: 
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receiving in a transcoding gateway from a client device one or more 
email display status attributes describing one or more email display 
capability statuses for a domain . . . 

That is 3 the Office Action takes the position that Shaffer at column 2, lines 30-65, and 
column 6, lines 31-53, discloses the first element of claim 1 . Applicants respectfully note 
in response, however, that what Shaffer at column 2, lines 30-65, in fact discloses is: 

A method and system for exchanging electronic messages, such as 
email messages, include out-tasking conversions of file formats when 
it is determined that a client device does not include the resources to 
directly access an attachment without conversion. The access 
requirements of each attachment to electronic messages are compared 
to the capabilities of the client device to which the attachment is to be 
transferred. If it is determined that a file-format conversion is required, 
the conversion operation is assigned to a server that supports the 
process of reformatting the attachment. In an email en vironment, the 
server may be substantially equivalent to the conventional email 
server, but includes enhanced conversion capabilities. 

In one embodiment, the determination of whether an attachment is 
accessible without conversion by a target client device occurs at the 
server. One means of enabling the server to execute the determination 
is to maintain a universal register of applications at the server. The 
universal register may be a lookup table that identifies each application 
program stored at each client device supported by the server. The 
lookup table may also include data that matches each user (i.e., 
potential recipient) with a client device at which the user typically 
accesses messages (e.g.. a target computer). When a message is 
received at the server, the file format of any attachment is identified. In 
its simplest form, this is accomplished by looking at the file extension 
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(e.g., .BMP identifies a bitmap graphics format and .MPEG indicates a 
specific video format). Alternatively, the format indicator may be 
embedded by the sending party within the message that includes the 
attachment. As a third possibility, the server may access each 
attachment in order to identify its file format If a file-format 
conversion is necessary, the conversion can be implemented at the 
server, thereby freeing resources and processing time at the target 
client device. In this embodiment, the conversion may be transparent 
to the receiving party. 

Furthermore, Applicants respectfully note in response, however, that what Shaffer at 
column 6, lines 31-53, in fact discloses is: 

At step 44, the access capabilities of the target client device 1 4, 1 6 and 
18 are determined. Referring to FIG. 1, an application register 34 may 
be maintained at the server level As is well known in the art, 
computers typically maintain an application register of programs 
stored at the computer. The application register 34 of FIG, 2 may be 
considered to be a universal application register that identifies all of 
the access capabilities of various client devices that are used to access 
email stored at the local server 12. In one embodiment, the application 
register is maintained as a lookup table. When a client device is first 
used to access email stored at the local server, the client device is 
polled to identify its access capabilities. The polling process may also 
be used to periodically update a lookup table that is compiled within 
memory of the server or within memory of an adjunct device. While 
the format converter 30 and the application register 34 are shown as 
being connected to the local server 1 2, the operations of the converter 
and register may be integrated into known servers. As an alternative to 
the polling approach, the client devices 14, ] 6 and 1 8 may be 
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programmed to identify their individual access capabilities each time 
that a program is upgraded or added to the client device- 

The first element of claim 1 claims receipt of email display status attributes. The only 
thing received in Shaffer is email messages with attachments. Shaffer mentions not one 
word regarding email display capability status. Email display capability status is 
exemplified in the present application by display device availability (reference 1904 on 
Figure 19) and display device recent usage (reference 1906 on Figure 19), but there is 
nothing like this in Shaffer. Shaffer's receipt of email messages and attachments 
therefore neither discloses nor suggests receiving email display status attributes as 
claimed in the present application. 

Shaffer Neither Discloses Nor Suggests The 
Second Element Of The Independent Claims 

Regarding the second element of claim 1, 8 and 15 the Office Action states that Shaffer 
discloses at column 6, lines 6-67 3 and column 7, lines 1-38: 

Receiving in the transcoding gateway from a sender an email display 
capability status request for the domain, wherein the capability status 
request comprises a domain identification . . . 

Paragraph 3 of the Office Action sets forth this further explanation of the 
rejection based on Shaffer 

a message sent by a sender to the server where a determination is made 
based on client capabilities, wherein said message would obviously be 
a default means of requesting capability status, especially in light of 
the fact that Shaffer discloses a capability status determination, a 
conversion means, and a notification to sender means, all related to the 
ability of the client/target device to receive the sender's message, and 
wherein the sender is notified of a client's inability to receive the 
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message based on conversion requirements, which requirements are 
obviously an indication of the client/domain ability/capability to 
receive the senders message. Additionally, the motivation to request 
client capability is also found within Shaffer which teaches the need 
for files to be accessible to the client device as well as a conversion 
consideration, wherein both conversion time and data loss are 
important access file/sharing issues, (Col. 1 ? lines 55-67 & Col. 2, lines 
1.27)); 



That is, the Office Action takes the position that Shaffer at column 6, lines 6-67 and 
column 7, lines 1-38 discloses the second element of claim 1, 8 and 15. Applicants 
respectfully note in response, however, that what Shaffer at column 6, lines 6-67 and 
column 7, lines 1-38 in feet discloses is transmission of an electronic message from a 
remote client device to a local server, identification of the file format of an attachment at 
the server level, determination of access capabilities of a target client device, 
determination whether the attachment is accessible at the target client device without 
conversion, conversion of the file format of the attachment locally or remotely as needed, 
and notification of the sender if conversion is not possible. None of which is a disclosure 
of receipt of an email display capability status request for a domain as claimed in the 
present application. 

The fact that receipt of an email display capability status request for a domain is not 
disclosed or suggested in Shaffer is implicitly admitted by the Office Action's argument: 



... a message sent by a sender to Ihe server where a determination is 
made based on client capabilities, wherein said message would 
obviously be a default means of requesting capability status ... 



That is, the Office Action argues that an email message is an email display capability 
status request for a domain, which it clearly is not. The email display capability status 
request as claimed here is a communication distinct from any email message, designed to 
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inform a sender of email display capability status during preparation of an email message, 
so that the sender can avoid the entire process of trial and error disclosed in Shaffer. In 
addition, the access capability of Shaffer discloses access capability only, disclosing 
nothing whatsoever regarding display capability status. Nothing in Shaffer ever detects 
or advises whether a display capability is actually available, powered on, for example, 
when a capability was recently used, or any other actual status information. 

Shaffer Neither Discloses Nor Suggests Th e 
Third Element Of The Independent Claims 

Regarding the third element of claim 1 , 8 and 15, the Office Action states that Shaffer 
discloses at column 67, lines 6-67, and column 7, lines 1-38: 

finding, in dependence upon the domain identification, at least one 
email display capability status record for the domain, wherein the 
email display capability status record for the domain comprises at least 
one of the email display capability status attributes, 

Regarding this third element of claim 1, the Office Action argues on page 3: 

Examiner notes that Shaffer discloses wherein if an attachment does 
not need conversion, it is transmitted to the client/target Moreover, 
Shaffer teaches a checking, determining and converting process, 
wherein the client does not intervene with the same, and wherein the 
client/target email display capability status attributes are determinative 
of the need for sender notification and/or conversion) ... 

That is, the Office Action takes the position that Shaffer at column 6, lines 6-67 and 
column 7, lines 1-38 discloses the third element of claim 1, 8 and 15. Applicants 
respectfully note in response, however, that what Shaffer at column 6, lines 6-67 and 
column 7, lines 1-38 in fact discloses is transmission of an electronic message from a 
remote client device to a l ocal server, identification of the file format of an attachment at 
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the server level, determination of access capabilities of a target client device, 
determination whether the attachment is accessible at the target client device without 
conversion, conversion of the file format of the attachment locally or remotely as needed, 
and notification of the sender if conversion is not possible. None of which is a disclosure 
of finding an email display capability status record for a domain as claimed in the present 
application. 

The fact that finding an email display capability status record for a domain is not 
disclosed or suggested in Shaffer is implicitly admitted by the Office Action's argument: 

. Moreover, Shaffer teaches a checking, determining and converting 
process, wherein the client does not intervene with the same . . . 

That is, the Office Action argues that Shaffer's checking and determining discloses 
finding an email display capability status record foT a domain, which it clearly does not 
Finding an email display capability status record for a domain as claimed here is a 
process that informs a sender of email display capability status for an entire destination 
domain during preparation of an email message, so that the sender can select a target 
device that is actually presently available and on-line, for example, and avoid the entire 
process of trial and error disclosed in Shaffer. In addition, the checking and determining 
of Shaffer is clearly oriented to a single target/client device and not to the display 
capability status of a domain as claimed here. Moreover, Shaffer's checking and 
determining administers access capability only, disclosing nothing whatsoever regarding 
display capability status. Nothing in Shaffer ever detects or advises whether a display 
capability is actually available, powered on, for example, when a capability was recently 
used, or any other actual status information. 

Shaffer Neither Discloses Nor Suggests The 
Fourth Element Of The Independent Claims 

Regarding the fourth element of claim 1, 8 and 15, the Office Action states that Shaffer 
discloses at column 6, lines 6-67, and column 7, lines 1-38, sending at least one of the 
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email display capability status attributes to the sender- That is, the Office Action takes 
the position that Shaffer at column 6, lines 6-67 and column 7, lines 1-38 discloses the 
fourth element of claim 1 , 8 and 15. In addition regarding this fourth element of claim 1, 
the Office Action on the bottom page 3 and continuing on the top of page 4 argues: 

. . . Examiner notes that Shaffer teaches sender notification concerning 
conversion requirements, which conversion requirement obviously 
represent client/target display capability status attributes . . , 

Applicants respectfully note in response, however, that what Shaffer at column 6 & lines 6- 
67 and column 7* lines 1-38 in fact discloses is transmission of an electronic message 
from a remote client device to a local server, identification of the file format of an 
attachment at the server level, determination of access capabilities of a tai-get client 
device, determination whether the attachment is accessible at the target client device 
without conversion, conversion of the file format of the attachment locally or remotely as 
needed, and notification of the sender if conversion is not possible. None of which is a 
disclosure of sending email display capability status attributes for a domain to a sender as 
claimed in the present application. 

Hie feet that finding an email display capability status record for a domain is not 
disclosed or suggested in Shaffer is implicitly admitted by the Office Action's argument: 

. . . Examiner notes that Shaffer teaches sender notification concerning 
conversion requirements, which conversion requirement obviously 
represent client/target display capability status attributes 

That is, the Office Action argues that Shaffer's sender notification of conversion 
requirements discloses sending email display capability status attributes for a domain to a 
sender, which it clearly does not. Sending email display capability status attributes for a 
domain to a sender as claimed here is a process that informs a sender of email display 
. capability status for an entire destination domain during preparation of an email message, 
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so that the sender can select a target device that is actually presently available and on- 
line, for example, and avoid the entire process of trial and error disclosed in Shaffer* In 
addition, the sender notification of conversion requirements in Shaffer is clearly oriented 
to a single target/client device and not to the display capability status of a domain as 
claimed here. Moreover, Shaffer's sender notification of conversion requirements 
administers access capability only, disclosing nothing whatsoever regarding display 
capability status. Nothing in Shaffer ever detects or advises whether a display capability 
is actually available, powered on, for example, when a capability was recently used, or 
any other actual status information. 

SHAFFER AND SCHWALM 

Claims 2, 3, 9, 10, 16, and 17 stand rejected for obviousness under 35 ILS.C § 103(a) as 
being unpatentable over Shaffer (U.S. Patent 6,092,114) in view of Schwalm, etal, (U.S. 
Patent No. 5,339,361 )* The proposed combination of Shaffer with Schwalm cannot 
establish a prima facie case of obviousness because the proposed combination does not 
teach each and every element of the claims of the present application, there is no 
suggestion or motivation to make the proposed combination, and there is no reasonable 
expectation of success in the proposed combination. 

The Combination Of Shaffer and Schwalm 
Does Not Teach all Of Applicants' Claim Limitation 

Because as shown above, Shaffer fails to disclose each and every element of independent 
claims 1, 8, and 15, the combination of Shaffer and Schwalm also fails to disclose each 
and every element of dependent claims 2, 3, 9, 10 fl 16, and 1 7, Because the Office Action 
cites Schwalm as teaching only additional claim limitations found in dependent claims 2, 
3, 9, 10, 16, and 17, that is, limitations in addition to the limitations of the independent 
claims, the combination of Shaffer and Schwalm cannot disclose each and every element 
of the referenced dependent claims because Schaffer does not disclose or enable the 
limitations of the independent claims for the reasons set forth above. Claims 2, 3, 9, 10, 
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16, and 17 are therefore patentable and the rejections under 35 U.S.C § 103 should be 
withdrawn. 

No Suggestion or Motivation to Combine Shaffer and Schwalm 

To establish a prima facie case of obviousness, there must be a suggestion or motivation 
to combine Shaffer and Schwalm. In re Vaeck, 947 F.2d at 493 9 20 USPQ2d at 1442. 
The suggestion or motivation to combine Shaffer and Schwalm must come from the 
teaching of the references themselves, and the Examiner must explicitly point to the 
teaching within Shaffer or Schwalm suggesting the proposed combination* Absent such a 
showing, the Examiner has impermissibly used "hindsight" occasioned by Applicants* 
own teaching to reject the claims. In re Surko, 1 1 F.3d 887, 42 U.S JP.Q,2d 1476 (Fed. 
Cir. 1997); In re Vaeck 947 F.2d 488m 20 U.S.P.Q,2d 1438 (Fed. Cir. 1991); In re 
Gorman, 933 F.2d 982, 986, 18 U.S.P.Q.2d 1885, 1888 (Fed. Cir. 1991); In re Bond, 910 
F.2d 831, 15 U.S.P.Q.2d 1566 (Fed. Cir. 1990); In re Laskowski, 871 F,.2d 115, 1 17, 10 
U.S.P.Q.2d 1397, 1398 (Fed. Cir. 1989). 

The Office Action makes no mention whatsoever of any place in either of the references 
or elsewhere that suggests or provides any motivation for the proposed combination of 
Shaffer or Schwalm* In fact, the Office Action makes no clear mention of motivation to 
combine at all. The closest the Office Action comes to discussing motivation to combine 
is two cryptic references to obviousness in paragraph 9, page 7: 

. . . wherein it would have been obvious to incorporate a sender verification 
means into the Shaffer system . * > 

and 

. . . wherein it would have been obvious to augment the Shaffer controlled access 
means by implementing sender verification as well. 
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Emphasis added. It is unclear, but perhaps these assertions of obviousness are intended 
somehow to show motivation to combine Shaffer and Schwalm, Applicants note in 
response, however, that these are both mete naked assertions for which no basis is 
provided from the art, neither from Shaffer, Schwalm, nor anywhere else. 

No Reasonable Expectation of Success in the 
Proposed Combination of Shaffer and Schwalm 

To establish a prima facie case of obviousness, there must be a reasonable expectation of 
success in the proposed modification of Shaffer. In re Merck & Co., Inc., 800 F.2d 1091 , 
1097, 231 USPQ 375, 379 (Fed. Cir. 1986). There can be no reasonable expectation of 
success in a proposed modification if the proposed modification changes the principle of 
operation of Shaffer. In re Ratti, 270 F.2d 810, 123 USPQ 349 (CCPA 1959). The 
principle of operation of Shaffer is automating file format conversions for attachments to 
email messages - with particular focus on where the conversion is to occur. Schwalm is 
a communications security case, disclosing a system and method for authenticating 
transmission and receipt of facsimile messages. There can be no reasonable expectation 
of success in a proposed combination of file fonnat conversion of Shaffer with facsimile 
message security of Schwalm to produce dynamic indications of client device status as 
claimed in the present application. The proposed modification of Shaffer by Schwalm 
therefore cannot possibly support a prima facie case of obviousness. 

Shaffer Teaches Away From Email Administration With 
Dynamic Indications Of Client Device Status 
As Claimed In The Present Application 

Shaffer actually teaches away from email administration with dynamic indications of 
client device status as claimed in the present application. Teaching away from the claims 
is a per se demonstration of lack of prima facie obviousness. In re Dow Chemical Co. , 
837 F.2d 469 3 5 U.S P.Q^d 1529 (Fed. Cir. 1988); In re Fine, 837 F.2d 1071, 5 
U.S.P.Q.2d 1596 (Fed. Cir. 1988); In re Neilson, 816 F.2d 1567, 2 U.S.P.Q.2d 1525 (Fed. 
Cir. 1987). The present application claims email administration with dynamic indications 
of client devi ce status. Shaffer in contrast teaches email attachment file format 
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conversion with no concern whatsoever for the actual status of any client device - 
thereby teaching directly away from the dynamic indications of client device status 
claimed in the present application. Even when the method of Shaffer finally gets around 
to advising a sender of a complete failure of conversion of an attachment, Shaffer never 
receives, detects, or communicates any information whatsoever regarding the status of 
the target device. Because Schaffer teaches away from email administration with 
dynamic indications of client device status as claimed in the present application, Shaffer 
cannot be used to support a prima facie case of obviousness. 

Schwalm Is Nonanalogou s Art 

Schwalm is nonanalogous art and is therefore unavailable as a reference under 35 U.S.C 
§ 103. "In order to rely on a reference as a basis for rejection of an applicants invention, 
the reference must either be in the field of applicant's endeavor or, if not, then be 
reasonably pertinent to the particular problem with which the inventor was concerned," In 
re Oetiker, 977 F.2d 1443, 1446, 24 USPQ2d 1443, 1445 (Fed. Cir. 1992). The field of 
endeavor of the present application is email administration with particular regard to 
dynamically indicating client device status for client devices for displaying digital objects 
included in email. Schwalm is a communications security case, disclosing a system and 
method for authenticating transmission and receipt of electronic information. The system 
of Schwalm is particularly oriented toward secure transmission of facsimile messages. 
An inventor attempting to solve problems related to displaying digital objects with email 
would never be reasonably expected to examine literature related to communications 
security for facsimile. The two are completely unrelated, that is, nonanalogous. 

Relations Among Claims 

Independent claim 1 claims method aspects of [preambl e] according to embodiments of 
the present invention* Independent claims 8 and 15 respectively claim system and 
computer program product aspects of [preamble] according to embodiments of the 
present invention. Claim 1 is allowable for the reasons set forth above. Claims 8 and 15 

14 

PAGE 16/18 1 RCVD AT 1/6«006 3:30:50 PM [Eastern Standard Timfi] * SVR:USPTO-EFXRF-6«0 8 DNIS:27K300 ^ CSID:5124729887 * DURATION (mm-ss):0444 



01/06/2006 14:30 5124729887 BIGGERS & OHANIAN PAGE 17/18 

AUS920010853US1 

are allowable because claim 1 is allowable. The rejections of claims 8 and 15 therefore 
should be withdrawn, and claims 8 and 15 should be allowed. 

Claims 2-7, 9-14, and 16-21 depend respectively from independent claims 1 3 8, and 15. 
Each dependent claim includes all of the limitations of the independent claim from which 
it depends. Because the combination of Shaffer and Schwalm does not disclose or 
suggest each and every element of the independent claims, so also the combination of 
Shaffer and Schwalm cannot possibly disclose or suggest each and every element of any 
dependent claim. The rejections of Claims 2-7, 9-14, and 16-21 therefore should be 
withdrawn, and these claims also should be allowed. 

Conclusion 

Claims 1,4-8, 11-15, and 18-21 stand rejected under 35 U.S.C § 103(a) as unpatentable 
over Shaffer and claims 2, 3, 9, 10, 16, and 17 stand rejected under 35 U.S.C § 103(a) as 
unpatentable over Shaffer in view of Schwalm. SchafFer alone or in combination with 
Schwalm does not disclose each and every element of Applicants' claims and does not 
enable Applicants' claims. Schaffer and Schwalm therefore do not anticipate Applicants* 
claims, Claims 1-21 are therefore patentable and should be allowed. Applicants 
respectfully request reconsideration of claims 1-21. 
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The Commissioner is hereby authorized to charge or credit Deposit Account No. 09-0447 
for any fees required or overpaid. 

Respectfully submitted, 




Date: January 6. 2006 Bv: 

" John Biggers ^ ^ 
Reg. No. 44,537 
Biggers & Ohanian, LLP 
P.O. Box 1469 
Austin, Texas 78767-1469 
Tel. (512) 472-9881 
Fax (512) 472-9887 
ATTORNEY FOR APPLICANTS 
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